home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16457 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: hypatia.pec.co.nz!JohnM
  2. From: JohnM@hypatia.pec.co.nz (John Marshall)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Followup-To: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  6. Date: 10 Apr 1996 23:07:35 GMT
  7. Organization: PEC (NZ) Ltd.
  8. Message-ID: <4khevn$26a@janus.pec.co.nz>
  9. References: <JSA.96Feb16135027@organon.com> <dewar.828879781@schonberg> <4k9qhe$65r@solutions.solon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg>
  10. Reply-To: johnm@pec.co.nz
  11. NNTP-Posting-Host: hypatia.pec.co.nz
  12. X-Newsreader: TIN [version 1.2 PL2]
  13.  
  14. Robert Dewar (dewar@cs.nyu.edu) wrote:
  15. > Peter said
  16. >> "How?  No offense meant, but any code which can be affected by this is flat
  17. >> out broken.  POSIX-style read is to be given a pointer to at least nbytes
  18. >> of space, for the information read.  Period."
  19. >
  20. > That's really confusing, the code in question DID give a buffer large
  21. > enough to hold nbytes of data, where nbytes is the number of bytes 
  22. > for "the information read". Maybe I don't understand, but reading the
  23. > above sentence, it sounds like you would be surprised by the Linux
  24. > behavior.
  25.  
  26. I think your confusion comes from misunderstanding what Peter is using
  27. "nbytes" to mean: he is referring to the parameter in the read() call.
  28.  
  29. > Here is the exact case. We declare a buffer of 100 bytes. We read a
  30. > 1000 bytes from a file whose total length is 68 bytes.
  31.  
  32. Can I try to demonstrate why this is unreasonable?  I don't have any
  33. definitive documentation here, but I believe the wording of the *contract*
  34. between application writer and library writer is something like:
  35.  
  36.   int read(int fd, char *buf, size_t nbytes)
  37.         Reads up to nbytes from fd into the buffer starting at buf.
  38.  
  39. How's this for a fair library routine which fulfills this:
  40.  
  41. /* "Pseudo-C" -- not real C, but you get the idea */
  42. int read(int fd, char *buf, size_t nbytes) {
  43.   int avail = fd->bytes_remaining;
  44.   if (avail >= nbytes) {
  45.     copy nbytes bytes from fd into buf[0..nbytes-1];
  46.     return nbytes;
  47.     }
  48.   else {
  49.     copy avail bytes from fd into buf[0..avail-1];
  50.     /* Try to protect the user a little bit from left over garbage: */
  51.     memset(&buf[avail], nbytes-avail, 0);  /* zero out buf[avail..nbytes-1] */
  52.     return avail;
  53.     }
  54.   }
  55.  
  56. (And in your case, of course, the memset hits memory in buf[68..999], and
  57. probably trashes about a kilobyte of your other variables.)
  58.  
  59. It seems to me that the contract says "the library routine may always expect
  60. to have nbytes of buffer space available at buf".  (Perhaps it says this
  61. only implicitly, which would be a shame.)  I think conforming implementations
  62. are free to use that buffer: maybe in a crazed attempt at helpfulness as
  63. above, or perhaps it's a fabulously tricky implementation and wants to use
  64. the buffer as temporary memory for its low-level file I/O.
  65.  
  66. > The code in question made 100% sure that the data read would never
  67. > exceed the buffer size, and I would have been hard pressed to
  68. > determine that the code was incorrect. 
  69.  
  70. So?  Does the specification say that read() will only touch what it
  71. _really_ needs to, or all of what the application has told it is available?
  72. Unfortunately, the answer seems to be "the specification is kinda vague", so
  73. pragmatically surely the more conservative assumption is more reasonable?
  74.  
  75. -- 
  76. John Marshall    <johnm@pec.co.nz>
  77. PEC (NZ) Ltd, Marton, New Zealand.
  78.